System and method for provisioning and unprovisioning multiple end points with respect to a subscriber and service management system employing the same

ABSTRACT

Various systems and methods for provisioning and/or unprovisioning an end point. One aspect provides a method of provisioning an end point. In one embodiment, the method include: (1) mapping the end point into a role in a service associated with a subscriber and (2) calling at least one function associated with the role, the function causing values to be transmitted to the end point to provision the end point with respect to the service.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims the benefit of U.S. Provisional Application Ser.No. 60/989,730, filed by Dholakia, et al., on Nov. 21, 2007, entitled“Method and System for Remote Device Management,” commonly assigned withthis application and incorporated herein by reference. This applicationis also related to the following U.S. patent applications, which arefiled on even date herewith, commonly assigned with this application andincorporated herein by reference:

Ser. No. Inventors Title [Attorney Dholakia, “Service Management Systemand Docket et. al. Method of Operation thereof” No. 804144- US-NP][Attorney Dholakia, “System and Method for Identifying Docket et. al.and Calling a Function of a Service No. With Respect to a Subscriber And804144- Service Management System Employing US-NP(2)] the Same”[Attorney Pelley, “Normalization Engine and Method of Docket et. al.Requesting a Key Or Performing an No. Operation Pertaining to an End804144- Point” US-NP(3)] [Attorney Pelley, “Service Management Systemand Docket et. al. Method of Executing a Policy” No. 804144- US-NP(4)][Attorney Pelley “System and Method for Generating a Docket VisualRepresentation of a Service No. and Service Management System 804144-Employing the Same” US-NP(5)] [Attorney Pelley, “System and Method forRemotely Docket et. al. Activating a Service and Service No. ManagementSystem Incorporating the 804144- Same” US-NP(6)] [Attorney Pelley“Application and Method for Docket Dynamically Presenting Data No.Regarding an End Point or a Service 804144- and Service ManagementSystem US-NP(7)] Incorporating the Same” [Attorney Pelley, “ServiceDiagnostic Engine and Docket et. al. Method and Service ManagementSystem No. Employing the Same” 804144- US-NP(8)] [Attorney Pelley“Self-Service Application for a Docket Service Management System andMethod No. of Operation Thereof” 804144- US-NP(9)] [Attorney Pelley“Customer Service Representative Docket Support Application for aService No. Management System and Method of 804144- Operation Thereof”US- NP(10)] [Attorney Pelley, “System and Method for Remotely Docket et.al. Repairing and Maintaining a No. Telecommunication Service Using804144- Service Relationships and Service US- Management SystemEmploying the NP(11)] Same” [Attorney Pelley, “Application and Methodfor Docket et. al. Generating Automated Offers of No. Service andService Management 804144- System Incorporating the Same” US- NP(12)][Attorney Dholakia, “System and Method for Identifying Docket et. al.Functions and Data With Respect to a No. Service and a Subscriber andService 804144- Management System Employing the US- Same” NP(14)][Attorney Dholakia, “System and Method for Invoking a Docket et. al.Function of a Service in Response to No. an Event and Service Management804144- System Employing the Same” US- NP(15)]

TECHNICAL FIELD

This application relates to remote management of fixed-line and mobiledevices, and, more particularly, to activation, provisioning, support,management and assurance of consumer and business services spanning oneor more fixed-line devices and one or more mobile devices.

BACKGROUND

Network service providers are called upon to support a large variety ofnetworked devices, including devices coupled to home networks (e.g.,residential gateways, set-top boxes and voice-over-IP, or VoIP,adapters) and cellular networks (e.g. smart phones and pocketcomputers). Given the proliferation of such devices and the distributednature of the networks involved, remote management of such devices ishighly desirable.

For example, demand for smart phones and other advanced handsets isgrowing faster than anticipated as users look for new ways to increasetheir personal and professional productivity. In 2005, year-over-yeargrowth in the smart phone market exceeded 70%, and the industry expertsexpect that trend to continue for the next several years. In fact by2009, it is estimated that smart phones will represent almost 30% of allnew handsets sold—up from less than three percent in 2004.

As smart phones and services for smart phones boom, so do thechallenges. Today, the complexity often associated with smart phones isdriving customer service costs up and serves as a potential inhibitor asmobile network operators strive to achieve mass-market adoption withthese sophisticated devices. In fact, consumers are finding mobileservices increasingly confusing and issues around ease-of-use areholding them back from buying and using third generation (3G) handsetsand services.

Wireless service providers who sell and support smart phones and theirassociated data services face the prospect of rising customer supportcosts due to the complexity associated with these devices and services.In 2007, the support costs for smart phones will surpass that of featurephones. The following are few of the top reasons for this support cost.

Multiple contacts are made to a helpdesk to solve a single problem.

34% of users have never solved a problem with a single contact to thehelpdesk.

Calls last two to three times longer than calls from users of featurephones.

It is common practice to escalate care from a helpdesk (Tier 1) toexpensive technicians (Tier 2 and Tier 3).

FMC (Fixed-Mobile Convergence) will add to the support burden. 89% ofearly adopters are more likely to go to CE vendors for support.Mainstream consumers are three times more likely to look to theirservice provider for support.

Similarly, network providers that are coupled to home networks (e.g.,Digital Subscriber Link, or DSL, and cable) find those networks coupledto a variety of customer premises equipment (CPE) within the homes thatare gradually becoming more and more sophisticated. Customer issues withsuch devices are no less taxing upon support staff and supportinfrastructure.

The Open Mobile Alliance (OMA) is currently defining a number ofstandards for managing functionality on mobile devices. These includeprotocols for device management (OMA-DM), client provisioning (OMA-CP),firmware updates, data synchronization (OMA-DS) and the like. Devicesthat support at least some of these protocols are becoming prevalent. Asupport solution that utilizes these protocols and provides a usableconsole for customer support is the only way network providers andmobile carriers can handle support for the increasing number of devicesin the market.

It is therefore desirable to provide a support solution that allowscentralized management and control of remotely networked devices such assmart phones and CPE using protocols established for device management,updates, data synchronization and the like.

SUMMARY

Various embodiments of a method and system for providing customersupport with centralized management and control of mobile phones andcustomer premises equipment in order to aid users of such equipment withproblems related to that equipment. In one embodiment, a user interfacedriven mechanism is provided to allow customer support representativesto manipulate remote devices in, for example, the following manners:access information about the remote devices and the users thereof,including history of issues with a particular device, deviceprovisioning, access to diagnostics of a device, ability to upgradefirmware/software of a device, synchronization of data, enablement ofsecurity features, remote control of devices, service and applicationprovisioning, defining and following policies related to servicemanagement for a variety of devices and resetting devices. Suchfunctionality can be provided, for example, through the use of a devicemanagement server that uses a variety of appropriate protocols tocommunicate with the remote devices.

Another aspect provides a method of provisioning an end point. In oneembodiment, the method include: (1) mapping the end point into a role ina service associated with a subscriber and (2) calling at least onefunction associated with the role, the function causing values to betransmitted to the end point to provision the end point with respect tothe service.

Yet another aspect provides a method of adding a device to a service. Inone embodiment, the method includes: (1) retrieving a list of servicedescriptions that are associated with a subscription from a servicerepository and (2) repeating, for each service description in the list:(2a) mapping the device into a current service description to determinewhether the device fits a role therein, (2b) if the target devicematches the role, retrieving an add device function from the currentservice description and (2c) if the target device matches the role,passing the function into the script engine.

BRIEF DESCRIPTION

Reference is now made to the following descriptions taken in conjunctionwith the accompanying drawings, in which:

FIG. 1 is a block diagram illustrating a network environment in whichcommercial transaction processing according to embodiments of theinvention may be practiced;

FIG. 2 is a block diagram illustrating a computer system suitable forimplementing embodiments of the invention;

FIG. 3 is a block diagram illustrating the interconnection of thecomputer system of FIG. 2 to client and host systems;

FIG. 4 is a diagram illustrating relationships that may exist among asubscriber, a service and various devices and systems;

FIG. 5 is a diagram of one embodiment of a service description;

FIG. 6 is a diagram illustrating relationships that may exist amongmanagement operations, roles, capabilities and attributes;

FIG. 7 is a high-level block diagram of one embodiment of a servicemanagement system;

FIG. 8 is a block diagram of one embodiment of a service normalizationblock of FIG. 7; and

FIG. 9 is a flow diagram of one embodiment of a method of adding adevice to, or removing a device from, a particular service.

DETAILED DESCRIPTION

The following is intended to provide a detailed description of anexample of the invention and should not be taken to be limiting of theinvention itself. Rather, any number of variations may fall within thescope of the invention which is defined in the claims following thedescription. The use of the same reference symbols in different drawingsindicates similar or identical items.

Introduction

Described herein are various embodiments of a management system thatallows users to create, define and maintain services by defining theroles of its constituent devices and systems. Certain of the embodimentshave the ability to map a given set of device and systems into roles.The roles may then be used to select key/value pairs, alerts andmanagement function from each device. Certain of the embodiments allowrelationships to be specified between roles and between other services.Using the roles and relationships as a lens upon the service'sconstituent devices, service-wide key/value pairs, alerts and managementfunctions may be created.

In various embodiments to be described and illustrated herein, a method,apparatus and process are disclosed that allow for activation,provisioning, support (by call center, functions or self), management(by call center, functions or self) and assurance of consumer andbusiness services spanning one or more fixed-line devices and one ormore mobile devices, such as PCs, AAA servers, email servers, webservers and devices of every kind. Before describing the embodiments, anexample computing and network environment within which the embodimentsmay operate will be described.

An Example Computing and Network Environment

FIG. 1 is a block diagram illustrating a network environment in which asystem according to the invention may be practiced. As is illustrated inFIG. 1, network 100, such as a private wide area network (WAN) or theInternet, includes a number of networked servers 110(1)-(N) that areaccessible by client computers 120(1)-(N).

Communication between the client computers 120(1)-(N) and the servers110(1)-(N) typically occurs over a publicly accessible network, such asa public switched telephone network (PSTN), a DSL connection, a cablemodem connection or large bandwidth trunks (e.g., communicationschannels providing T1 or OC3 service). The client computers 120(1)-(N)access the servers 110(1)-(N) through, for example, a service provider.This might be, for example, an Internet Service Provider (ISP) such asAmerica On-Line™, Prodigy™, CompuServe™ or the like. Access is typicallyhad by executing application specific software (e.g., network connectionsoftware and a browser) on the given one of the client computers120(1)-(N).

One or more of the client computers 120(1)-(N) and/or one or more of theservers 110(1)-(N) may be, for example, a computer system of anyappropriate design, in general, including a mainframe, a mini-computeror a personal computer system. Such a computer system typically includesa system unit having a system processor and associated volatile andnon-volatile memory, one or more display monitors and keyboards, one ormore diskette drives, one or more fixed disk storage devices and one ormore printers. These computer systems are typically information handlingsystems which are designed to provide computing power to one or moreusers, either locally or remotely. Such a computer system may alsoinclude one or a plurality of I/O devices (i.e., peripheral devices)which are coupled to the system processor and which perform specializedfunctions. Examples of I/O devices include modems, sound and videodevices and specialized communication devices. Mass storage devices suchas hard disks, CD-ROM drives and magneto-optical drives may also beprovided, either as an integrated or peripheral device. One suchexample, computer system, discussed in terms of the client computers120(1)-(N), is shown in detail in FIG. 2.

It will be noted that the variable identifier “N” is used in severalinstances in FIG. 1 to more simply designate the final element (e.g.,the servers 110(1)-(N) and the client computers 120(1)-(N)) of a seriesof related or similar elements (e.g., servers and client computers). Therepeated use of such variable identifiers is not meant to imply acorrelation between the sizes of such series of elements, although suchcorrelation may exist. The use of such variable identifiers does notrequire that each series of elements has the same number of elements asanother series delimited by the same variable identifier. Rather, ineach instance of use, the variable identified by “N” may hold the sameor a different value than other instances of the same variableidentifier.

FIG. 2 depicts a block diagram of a computer system 210 suitable forimplementing the invention and example of one or more of the clientcomputers 120(1)-(N). A computer system 210 includes a bus 212 whichinterconnects major subsystems of the computer system 210 such as acentral processor 214, a system memory 216 (typically random-accessmemory, or RAM, but which may also include read-only memory, or ROM,flash RAM, or the like), an input/output controller 218, an externalaudio device such as a speaker system 220 via an audio output interface222, an external device such as a display screen 224 via a displayadapter 226, serial ports 228, 230, a keyboard 232 (interfaced with akeyboard controller 233), a storage interface 234, a floppy disk drive236 operative to receive a floppy disk 238 and a CD-ROM drive 240operative to receive a CD-ROM 242. Also included are a mouse 246 (orother point-and-click device, coupled to the bus 212 via the serial port228), a modem 247 (coupled to the bus 212 via the serial port 230) and anetwork interface 248 (coupled directly to the bus 212).

The bus 212 allows data communication between a central processor 214and a system memory 216, which may include RAM, ROM or flash memory, aspreviously noted. The RAM is generally the main memory into which theoperating system and application programs are loaded and typicallyaffords at least 16 megabytes of memory space. The ROM or flash memorymay contain, among other code, the Basic Input-Output system (BIOS)which controls basic hardware operation such as the interaction withperipheral components. Applications resident with the computer system210 are generally stored on and accessed via a computer readable medium,such as a hard disk drive (e.g., fixed disk 244), an optical drive(e.g., CD-ROM drive 240), a floppy disk unit 236 or other storagemedium. Additionally, applications may be in the form of electronicsignals modulated in accordance with the application and datacommunication technology when accessed via a network modem 247 or aninterface 248.

The storage interface 234, as with the other storage interfaces of thecomputer system 210, may connect to a standard computer readable mediumfor storage and/or retrieval of information, such as a fixed disk drive244. The fixed disk drive 244 may be a part of computer system 210 ormay be separate and accessed through other interface systems. Many otherdevices can be connected, such as a mouse 246 connected to the bus 212via serial port 228, a modem 247 connected to the bus 212 via serialport 230 and a network interface 248 connected directly to the bus 212.The modem 247 may provide a direct connection to a remote server via atelephone link or to the Internet via an internet service provider(ISP). The network interface 248 may provide a direct connection to aremote server via a direct network link to the Internet via a POP (pointof presence). The network interface 248 may provide such connectionusing wireless techniques, including digital cellular telephoneconnection, Cellular Digital Packet Data (CDPD) connection, digitalsatellite data connection or the like.

Many other devices or subsystems (not shown) may be connected in asimilar manner (e.g., bar code readers, document scanners, digitalcameras and so on).

Conversely, it is not necessary for all of the devices shown in FIG. 2to be present to practice the invention. The devices and subsystems maybe interconnected in different ways from that shown in FIG. 2. Theoperation of a computer system such as that shown in FIG. 2 is readilyknown in the art and is not discussed in detail in this application.Code to implement the invention may be stored in computer-readablestorage media such as one or more of the system memory 216, the fixeddisk 244, the CD-ROM 242 or the floppy disk 238. Additionally, thecomputer system 210 may be any kind of computing device and so includespersonal data assistants (PDAs), network appliance, X-window terminal orother such computing device. The operating system provided on thecomputer system 210 may be MS-DOS®, MS-Windows®, OS/2®, UNIX®, Linux® orother known operating system. The computer system 210 may also support anumber of Internet access tools, including, for example, a HypertextTransfer Protocol (HTTP)-compliant web browser having a JavaScriptinterpreter, such as Netscape Navigator® 3.0, Microsoft Explorer® 3.0and the like.

The foregoing described embodiment wherein the different components arecontained within different other components (e.g., the various elementsshown as components of the computer system 210). It is to be understoodthat such depicted architectures are merely examples, and that in fact,many other architectures can be implemented which achieve the samefunctionality. In an abstract, but still definite sense, any arrangementof components to achieve the same functionality is effectively“associated” such that the desired functionality is achieved. Hence, anytwo components herein combined to achieve a particular functionality canbe seen as “associated with” each other such that the desiredfunctionality is achieved, irrespective of architectures or intermediatecomponents. Likewise, any two components so associated can also beviewed as being “operably connected,” or “operably coupled,” to eachother to achieve the desired functionality.

FIG. 3 is a block diagram depicting a network 300 in which the computersystem 210 is coupled to an internetwork 310, which is coupled, in turn,to client systems 320, 330, as well as a server 340. An internetwork 310(e.g., the Internet or a wide-area network, or WAN) is also capable ofcoupling the client systems 320, 330 and the server 340 to one another.With reference to the computer system 210, the modem 247, the networkinterface 248 or some other method can be used to provide connectivityfrom the computer system 210 to the internetwork 310. The computersystem 210, the client system 320 and the client system 330 are able toaccess information on the server 340 using, for example, a web browser(not shown). Such a web browser allows the computer system 210, as wellas the client systems 320, 330, to access data on the server 340representing the pages of a website hosted on the server 340. Protocolsfor exchanging data via the Internet are well known to those skilled inthe art. Although FIG. 3 depicts the use of the Internet for exchangingdata, the invention is not limited to the Internet or any particularnetwork-based environment.

Referring to FIGS. 1, 2 and 3, a browser running on the computer system210 employs a TCP/IP connection to pass a request to the server 340,which can run an HTTP “service” (e.g., under the WINDOWS® operatingsystem) or a “daemon” (e.g., under the UNIX® operating system), forexample. Such a request can be processed, for example, by contacting anHTTP server employing a protocol that can be used to communicate betweenthe HTTP server and the client computer. The HTTP server then respondsto the protocol, typically by sending a “web page” formatted as an HTMLfile. The browser interprets the HTML file and may form a visualrepresentation of the same using local resources (e.g., fonts andcolors).

Example Embodiments of a Service Management System

The functions referred to herein may be modules or portions of modules(e.g., software, firmware or hardware modules). For example, althoughthe described embodiment includes software modules and/or includesmanually entered user commands, the various example modules may beapplication specific hardware modules. The software modules discussedherein may include script, batch or other executable files, orcombinations and/or portions of such files. The software modules mayinclude a computer program or subroutines thereof encoded oncomputer-readable media.

Additionally, those skilled in the art will recognize that theboundaries between modules are merely illustrative and alternativeembodiments may merge modules or impose an alternative decomposition offunctionality of modules. For example, the modules discussed herein maybe decomposed into sub-modules to be executed as multiple computerprocesses and, optionally, on multiple computers. Moreover, alternativeembodiments may combine multiple instances of a particular module orsub-module. Furthermore, those skilled in the art will recognize thatthe functions described in example embodiment are for illustration only.Operations may be combined or the functionality of the functions may bedistributed in additional functions in accordance with the invention.

Alternatively, such actions may be embodied in the structure ofcircuitry that implements such functionality, such as the micro-code ofa complex instruction set computer (CISC), firmware programmed intoprogrammable or erasable/programmable devices, the configuration of afield-programmable gate array (FPGA), the design of a gate array orfull-custom application-specific integrated circuit (ASIC), or the like.

Each of the blocks of the flow diagram may be executed by a module(e.g., a software module) or a portion of a module or a computer systemuser using, for example, a computer system such as the computer system210. Thus, the above described method, the functions thereof and modulestherefore may be executed on a computer system configured to execute thefunctions of the method and/or may be executed from computer-readablemedia. The method may be embodied in a machine-readable and/orcomputer-readable medium for configuring a computer system to executethe method. Thus, the software modules may be stored within and/ortransmitted to a computer system memory to configure the computer systemto perform the functions of the module.

Such a computer system normally processes information according to aprogram (a list of internally stored instructions such as a particularapplication program and/or an operating system) and produces resultantoutput information via I/O devices. A computer process typicallyincludes an executing (running) program or portion of a program, currentprogram values and state information and the resources used by theoperating system to manage the execution of the process. A parentprocess may spawn other, child processes to help perform the overallfunctionality of the parent process. Because the parent processspecifically spawns the child processes to perform a portion of theoverall functionality of the parent process, the functions performed bychild processes (and grandchild processes, etc.) may sometimes bedescribed as being performed by the parent process.

Such a computer system typically includes multiple computer processesexecuting “concurrently.” Often, a computer system includes a singleprocessing unit which is capable of supporting many active processesalternately. Although multiple processes may appear to be executingconcurrently, at any given point in time only one process is actuallyexecuted by the single processing unit. By rapidly changing the processexecuting, a computer system gives the appearance of concurrent processexecution. The ability of a computer system to multiplex the computersystem's resources among multiple processes in various stages ofexecution is called multitasking. Systems with multiple processingunits, which by definition can support true concurrent processing, arecalled multiprocessing systems. Active processes are often referred toas executing concurrently when such processes are executed in amultitasking and/or a multiprocessing environment.

The software modules described herein may be received by such a computersystem, for example, from computer readable media. The computer readablemedia may be permanently, removably or remotely coupled to the computersystem. The computer readable media may non-exclusively include, forexample, any number of the following: magnetic storage media includingdisk and tape storage media, optical storage media such as compact diskmedia (e.g., CD-ROM, CD-R, etc.) and digital video disk storage media,nonvolatile memory storage memory including semiconductor-based memoryunits such as flash memory, EEPROM, EPROM, ROM or application-specificintegrated circuits (ASICs), volatile storage media including registers,buffers or caches, main memory, RAM and the like, and data transmissionmedia including computer network, point-to-point telecommunication andcarrier wave transmission media. In a UNIX-based embodiment, thesoftware modules may be embodied in a file which may be a device, aterminal, a local or remote file, a socket, a network connection, asignal, or other expedient of communication or state change. Other newand various types of computer-readable media may be used to store and/ortransmit the software modules discussed herein.

Before describing various embodiments of management systems constructedaccording to the principles of the invention, some use cases orinteractions will be described that provide a framework forunderstanding the management systems. Various of the embodiments of themanagement systems are directed to addressing the following categoriesof use cases or interactions: service activation, service management,service interruption and resumption and service offering. Serviceactivation refers to all the use cases that involve creating(provisioning) and deleting (unprovisioning) a new service instance, or“subscription.” Service management refers to day-to-day management tasksinvolving a given service or subscription. Service interruption andresumption may be thought of as special types of service management thatinvolve the loss and restoration of service. Service offering refers tonew services that may be offered to a subscriber.

The categories of use cases that set forth above may be illustrated withreference to FIG. 4. FIG. 4 is a diagram illustrating relationships thatmay exist among a subscriber 410, a service 420 and various devices andsystems 430. A service provider, such as a cellular phone company, anInternet service provider, a cable television company or a combinationof these, offers one or more services to subscribers that involvedevices and systems such as cell phones, set-top boxes, routers, celltowers, email servers, DSLAMs, landline phones and other mobile andcustomer premises equipment and network infrastructure. In the contextof FIG. 4, the subscriber 410 takes out a subscription 440 to a service420 offered by a service provider. The subscription contains state andother information that is both relative to the subscriber 410 and theservice 420. The subscription calls for one or more associations 450 tobe made between the subscriber 410 and various devices and systems 430.The subscriber 410 may own or lease one or more devices 430. Thesubscriber 410 may also be associated with one or more systems 430. Oncethe associations 450 are made, the devices and systems 430 assume roles460 in delivering the service 420 to the subscriber 410. The rolesdescribe to the service management system how the device should bemanaged.

FIG. 4 may be employed to illustrate two example use cases: activating adevice for a subscriber and managing and provisioning a subscription.

To activate a device (one of the devices and systems 430) for asubscriber 410, the following steps may be taken. First, for a givendevice 410, the subscriber 410 associated with that device 430 is found.This is done by employing the associations 450. Once the associatedsubscriber 410 has been identified, a corresponding subscription 440 maythen be used to determine the service or services 420 that should beprovisioned on the device 430. For each service 420 that needs to beactivated on the device 430, two alternative actions may be taken. Basedupon the role the device 430 plays with respect to the service 420,settings on the device 430 may be set to provision the device.Alternatively or additionally, based on the roles of other devices andsystems 430 relative to the service 420, settings on the other devicesand systems may be set to provision them for the new device's presence.

Managing and provisioning a subscription involves either adding a newservice to a subscriber or managing an existing service. To manage andprovision a subscription 440 for a subscriber 410, the following stepsmay be taken. First, a service 420 is added to a subscriber 410, or anexisting service 420 is modified. Devices and systems 430 associatedwith the subscriber are collected. Then, each device associated with theservice 420 is mapped into the different roles 460 in the targetedservice. This reveals what actions should be taken with respect to eachdevice or system to provision the service 420.

Another use case that is a variant on the one above is a bulk change toan existing service for all subscribers. In this use case, existingsubscriptions are retrieved to obtain a list of subscribers. Then, alist of devices and systems 430 is assembled for each subscriber. Usingroles, changes are then applied to the devices and systems 430 to enablethe bulk change.

Having described various use cases, one manner in which interaction mayoccur among roles, devices and systems, and the service level managementinterfaces will now be described. FIG. 5 is a diagram of one embodimentof a service description 500. FIG. 5 shows that the service description500 includes service alerts 505, functions 510 and key/value pairs 515.Roles are associated with the service alerts 505, the functions 510 andthe key/value pairs 515. The roles, designated Role A 520, Role B 525and Role C 530 are associated as shown with the service alerts 505, thefunctions 510 and the key/value pairs 515 as various arrows show. Metadata 535 is also associated with the key/value pairs 515. Devices orsystems 540, 545 are associated with the roles 520, 525, 535 as variousarrows show.

FIG. 5 illustrates, in the context of the service description 500, how aset of roles (e.g., the roles 520, 525, 535) can be mapped onto a set ofdevices and systems (e.g., the devices or systems 540, 545). The rolesdefine the functions, alerts and functions that are of interest fromeach device or system. In the illustrated embodiment, the meta data 535contains both service-wide and subscriber/subscription data that isspecific to the service description. Items like level of service andcurrent state of activation would be a part of the meta data. Thealerts, functions, and key/value pairs 505. 510, 515 together constituteservices supported by the devices and systems 540, 545 exposed throughthe roles 520, 525, 530. The service description 500 is configured tocontain arbitrary, named relationships that can be used to affect aservice. The service description 500 may also be configured to containone or more references to other service with which it has relationshipsor upon which it has dependencies. Accordingly, a further servicedescription 550 is associated with the meta data 535 as an arrow shows.Similar to the relationships between roles, relationships betweenservices are exposed to the logic in the service description and toexternal logic associated with the service description.

To make a role useful, the role is matched with a device. FIG. 6 is adiagram illustrating relationships that may exist among managementfunctions (i.e., values, alerts and functions 505, 510, 515), roles(e.g., 460), capabilities and attributes 610 and devices and systems(e.g., 430). In the embodiment of FIG. 6, the mechanism for doing thisis twofold. First, a role may be matched to a device or a system basedon the known attributes of the device or system. Second, a role may bematched to a device or a system based upon the known capabilities of thedevice or system.

Device attributes are known aspects of the device, e.g., the type,serial number, MAC address, manufacture date, make, model, service tags,device ID or operating system of the device or system. Other attributesmay include the firmware version, hardware version, embedded device,locale (language), and physical location. Device attributes, in thesimplest form, could be a list of known key/value pairs associated tothe device.

Capabilities are similar to device attributes. In this case, instead ofa list of key/value pairs, these are a list of values (without the key)of known capabilities about the device, e.g., generic email client,Microsoft Outlook® email client, phone, router or IPTV device. Otherexamples include network attached storage, media server, media renderer,camera, MMS client, SMS client, wireless access provider, wirelessaccess client, printer, GPS, vibrate, Bluetooth, USB, Wi-Fi, clock,browser, QVGA, flight mode, caller ID, touch screen, or fax.

Both the capabilities and the attributes can be provided to or retrievedfrom an external system, deduced or derived from known attributes andcapabilities, queried directly from the device or system or acombination of these. For example, prior knowledge may exist that anydevice that has a serial number from a given manufacture starting withthe letter W—has built-in Wi-Fi capabilities, or that Windows® Mobilephone supports OMA-DM.

It can be determined whether a given device or system matches a role bymatching its attributes and capabilities (derived, discovered, or known)against the required attributes and capabilities of a given role. Eachrole defines a set of key/value pairs, alerts, and functions that arerelevant for devices of that role in the service description.

It should be noted that roles do not imply device type, model or brand.Direct mappings between devices and roles may occur in practice, but themappings are flexible such that they may change as device attributes orcapabilities change. For example, newer devices may support more rolesthan do older devices. One example of a role is a phone capable offunctioning as an email client may play an “EmailClient” role in aservice description associated with an email service. Other roles in anemail service may include “SMTPServer,” “POPServer” and “IMAPServer.”Roles in a data connectivity service may include “Host,” “Router,”“Wireless Access Point,” “Head End,” “Border Gateway” and“Authentication, Authorization, Account Server.”

FIG. 7 is a high-level block diagram of one embodiment of a servicemanagement system. The service management system includes a servicenormalization block 705 that will be described in greater detail inconjunction with FIG. 8 below. The service normalization block interactswith an optimal settings block 710, a device (and/or system)normalization block 715, a diagnostic engine block 720 and a contentrepository block 725. A segmentation block 730 and a knowledge base 735interact with the optimal settings block 710, the device normalizationblock 715, the diagnostic engine block 720 and the content repositoryblock 725 as shown.

The service normalization block 705 employs an application programminginterface (API), allowing it to exchange information with an interactivevoice response (IVR) system 745, a console 750 for a customer servicerepresentative (CSR), a Self-Service Management (SSM) application module755 and other applications 760, 765 as may be found advantageous in aparticular environment.

The optimal settings block 710 is a repository of predefined known goodvalues used for the purposes of comparing key/value pairs to determinediagnostic and state information. The key/value pairs are also usedduring provisioning to set up a system or a device. The optimal settingsblock 710 may be regarded as a configuration repository that containsmeta data about the configuration so that applications and other systemscan look up known good values for the purpose of configuring(provisioning), diagnostic, and repair. The illustrated embodiment ofthe optimal settings block 710 is configured to define optimal valuesfor any given key/value pair based on the context of the device,subscriber, customer, or any other segmentation scheme that could be useto define different values for the same attribute (key). These valuesmay be used by both the script engine 830 and directly by the servicemanagement engine 805 to determine whether or not a given key/value pairis “optimal.” Optimal values may fall into three categories: (1) valuespredefined in the context of the service as being correct, (2) valuesdefined based by a call to an extrinsic system or by subscriber input asbeing correct and (3) absolute values (which is often built into thelogic of the script or service description logic and not storedexternally). An example of a predefined optimal value is a POP server.The subscriber is aware of its identity, and it is the same for allsubscribers. An example of an absolute value is “connectivity good.” Anexample of a value defined by a subscriber as being correct is apassword, something that the subscriber chooses and is not definedbefore the subscriber chooses it.

The device normalization block 715 is configured to map normalizedkey/value pairs to device-specific or system-specific key value pairs.Mapping may be performed by transformation, executing a script, orundertaking any other appropriate normalization mechanism.

The diagnostic engine 720 is configured to contain diagnostic rules andcause diagnostic rules to be executed in order to identify, characterizeand present potential solutions to problems that may exist with devicesor systems. The content repository is configured to provide achannel-independent mechanism for associating bearer (e.g., IVR voiceflows, self-service portal web content and customer service articles) todiagnose a problem.

The segmentation block 730 and knowledge base 735 likewise employ a datasources abstraction layer 770, allowing it to communicate with systems775, 790 and provisioning servers and device managers 780, 785.

Different subscribers subscribe to different levels of service and livein different locations and under different circumstances. Thesegmentation block 730 is configured to enable other portions of theservice management system to tailor responses to a subscriber based onhis level of service, location and/or circumstance.

The knowledge base 735 is configured to contain articles associated withknown device, system and/or service problems. When the diagnostic engine720 identifies a problem area or a specified problem, it may providearticles from the knowledge based 735 to an application to allow theapplication to provide the article in turn to a subscriber or other userfor informational purposes.

The data sources abstraction layer 770 is configured to operate as aprotocol implementation and adaptation layer, allowing generic logic tointeract with specific devices and systems without having to employ adevice-specific or system-specific protocol.

The systems 775, 790 are typically added by a particular serviceprovider and interact with the service management system as needed. Theprovisioning servers and device managers 780, 785 support variousdevices 795 intended for use by subscribers. In the illustratedembodiment, the provisioning servers and device managers 780, 785 aremanagement systems that manage large groups of devices that typicallyshare the same protocol (e.g., a mobile device manager that manages 10million phones using the OMA-DM protocol). The devices 795 are just CPE,such as phones and routers.

FIG. 8 is a block diagram of one embodiment of the service normalizationblock 705. The API 740 provides a mechanism by which the servicenormalization block 705 may be called from within and without theservice management system. By means of the API 740, subscribers may haveservices added (provisioned), removed (unprovisioned), modified orotherwise managed. Devices of subscribers may also be managed in thecontext of a particular service. Management access to key/value pairs ofconstituent devices and systems may also be dynamically determined andmanaged based on their roles in providing particular services.

A service management engine 805 enables a service provider to implementand manage services by means of the service normalization block 705according to the various use cases described above. The illustratedembodiment of the service management engine 805 functions in two primaryways. First, the service management engine 805 manages functions definedby service descriptions. Second, the service management engine 805provides a dynamic view of a given service.

The management of functions allows service descriptions to define namedfunctions that can be called with contextual data derived from analyzingconstituent devices and systems in their associated roles of a service.

The provision of a dynamic view of a given service enables a servicedescription to associate key/value pairs (data) with different roles anddynamically to gather data from the devices and systems so that data canbe presented without the need for intrinsic knowledge of the data thatis being collected. For example, a service-view dashboard capable ofcreating a map of devices with their associated data of interest (eachcategorized by their role in the service) may employ dynamic views ofservices. In the illustrated embodiment, the data itself isself-describing and typically presented in tabular form.

In an alternative embodiment, the service management engine 805 is alsocapable of providing a view of a given service, in which case theapplication does have prior intrinsic knowledge regarding the data thatis being collected.

The first step in managing the service is to collect a list of thedevices and systems that are associated to the subscriber of theservice. A device repository 835 serves this purpose. In the illustratedembodiment, the device repository is external to the servicenormalization block 705.

The service management engine 805 employs a capabilities repository toobtain an expanded view on the capabilities of a device so that it maymap it into a role. Often the only pieces of information obtained fromextrinsic systems are the unique identifier of the device, e.g., itsmake and model. A device may be viewed as a list of attributes (e.g.,further key/value pairs). From those attributes, the capabilities of thedevice may be extrapolated. Extrapolation may involve expanding theknown attributes of a device by deriving new attributes of a devicebased on the original attributes. For example, once the make and modelof a system or device is obtained by means of a query, built-in rulesmay then be able to determine whether or not it has Wi-Fi capability.

A service description repository contains service descriptions. Asdescribed above, a service description includes at least some of:functions, key/value pairs, alerts, roles (along with their associatedkey/value pairs, alerts and actions) and relationships. Functions, atthe service description level, can be actions exposed by a device, ascript that can be executed, or a process (a series of scripts executedin a state engine).

A script engine 830 is configured to execute service-level functions. Asdescribed previously, a service-level function could be a script, aprocess or action (a series of scripts) or any other type of computerprogram. In the illustrated embodiment, the service management engine805 retrieves a named script from a service description based on anevent or request from a consumer of the service and passes it, alongwith a set of parameters, to the script engine 805 for execution. In theillustrated embodiment, the set of parameters includes: references tothe constituent devices (categorized by role) and the servicedescription. The script, once started, has access to the optimal values,the devices and systems (abstracted by device normalization or directly)and the service management system in general.

The service normalization block 705 has access to a capabilitiesrepository 820. The capabilities repository 820 is configured to derivenew attributes and capabilities through rules based on existing, knownattributes. For example, it is known that Windows® Mobile cell phoneshave Internet browsers.

The service normalization block 705 employs the device normalizationengine 715 configured to create an abstraction that provides a normalview of extrinsic device and systems. This allows the servicedescription to be defined generically for devices and systems of thesame class without having to include logic and cases for each device.For example, if one device is managed by OMA-DM and has an email clientwhile another device that also has an email client is managed by DigitalSubscriber Line (DSL) Forum standard TR069, both devices will have aSimple Mail Transfer Protocol (SMTP) server. However, the manner inwhich values are obtained can differ by protocol (OMA-DM versus TR069)and by key (the name for the value).

At least some of the systems and devices 775, 795 have the capability togenerate alerts or events. The alert/event engine 815 is configured toreceive these alerts or events and apply them against each servicedescription to determine whether the alert applies to that servicedescription. If a particular alert or event does apply to a particularservice, the service management system is configured to obtain acorresponding action, script or process from the service descriptionthat may be executed to respond to the alert or event.

Provisioning and Unprovisioning Multiple End Points

Described hereinafter are various systems and methods for provisioningand/or unprovisioning a device or a system with respect to the servicesto which a given subscriber has a subscription. In one embodiment, amethod of provisioning and/or unprovisioning includes mapping the deviceor system into the role or roles it may play in each of the subscriber'sservices. Then, for each role the device or system is mapped into,specific functions associated with the service description for each ofthe services is called for the purpose of adding the device or serviceto, and/or removing the device or system from, the service. Thefunctions may also use the service description and other devices orsystems that are associated with the subscriber (which are mapped intoroles in the service) to modify, update, remove, configure, manage ortake any other action with respect to the other devices or systems,depending upon their role.

For example, a user buys a new cellphone. The cellphone is registeredwith a wireless network, which causes a notice to be generated to theeffect that a subscriber has added a new cellphone. The subscriberassociated with the new phone is identified. Then, the services to whichthe subscriber has subscriptions are determined, and their associatedservice definitions are retrieved. For each service definition, anyroles that the new cellphone may play are determined. If such a role isfound, an “AddDevice” function (associated with the role) is called,causing appropriate values to be transmitted to the cellphone and anyother devices or systems so that the cellphone is properly provisioned.

FIG. 10 is a flow diagram of one embodiment of a method of adding adevice to, or removing a device from, a particular service. The methodbegins in a start step 1005, when it is desired to add a device orsystem to a service. In a step 1010, a list of service descriptions thatare associated with the subscriber's subscriptions is retrieved from theservice repository. In a step 1015, an analytical process is repeatedfor each service description.

One step in the analytical process, a step 1020, calls for the targetdevice to be mapped into the current service description to determinewhether it fits a role in the current service description. In anotherstep, a decisional step 1025, it is determined whether or not the targetdevice matches a role in the current service description. If not, thenext service description is analyzed. If so, the analytical process, ina step 1030, calls for the add device function to be retrieved from thecurrent service description. Then, in a step 1040, the function ispassed into the script engine with the service description and thedevices and services categorized by role.

Once the analytical process of the steps 1020 to 1035 are repeated foreach service description, results from the different functions areretrieved and returned in a step 1040.

Those skilled in the art to which this application relates willappreciate that other and further additions, deletions, substitutionsand modifications may be made to the described embodiments.

1. A method of provisioning an end point, comprising: mapping said endpoint into a role in a service associated with a subscriber; and callingat least one function associated with said role, said function causingvalues to be transmitted to said end point to provision said end pointwith respect to said service.
 2. The method as recited in claim 1wherein said method is further a method of unprovisioning said endpoint, said method further comprising calling another functionassociated with said role and configured to cause values to betransmitted to unprovision said end point with respect to said service.3. The method as recited in claim 2 wherein said other function causesones of said values to be transmitted to said end point.
 4. The methodas recited in claim 1 wherein said end point is selected from the groupconsisting of: a device, and a system.
 5. The method as recited in claim1 wherein said calling comprises calling further functions configured totake other actions with respect to other end points to provision saidend point.
 6. A method of adding a device to a service, comprising:retrieving service descriptions that are associated with a subscriptionfrom a service repository; and repeating, for each service descriptionin said list: mapping said device into a current service description todetermine whether said device fits a role therein, if said target devicematches said role, retrieving an add device function from said currentservice description, and if said target device matches said role,passing said function into said script engine.
 7. The method as recitedin claim 6 wherein said passing said function further comprises passingsaid service description and end points into said script engine.
 8. Themethod as recited in claim 7 wherein said end points are categorized byrole.
 9. The method as recited in claim 7 wherein said end points areselected from the group consisting of: devices, and systems.
 10. Themethod as recited in claim 6 further comprising: retrieving results fromsaid function; and returning said results to an application.